
\subsection{Extraction Component}
%Extraction component is designed for collecting two categories of
%information: (1) data structure definitions and (2) external and
%shared APIs. %Extraction component is implemented by extending the
%\texttt{gcc} parser.

\vspace{0.1in} \noindent \textbf{Extracting Data Structures.} % We
%collect the data structure information in the function
%\texttt{c\_parser\_struct\_}-\texttt{or\_union\_specifier}
%(gcc/c-parser.c).
When we encounter a data structure definition, we record the name of
the data structure, the number of the fields, as well as the name,
size and offset for each field. %Note that we use the name and number
%of fields to uniquely identify the data structure.

There are two practical challenges when calculating the offset for a
data structure field during the parsing phase. One is the alignment
problem. The compiler often adds an alignment to the memory layout
of the data structure based on different compiler options (e.g.,
\#pragma pack(n)). On the x86 32 bits architecture, the default
alignment rule is, if the size of the field is no less than 4, it
will be aligned by 4. If the size of the field equals to 2, it will
be aligned by 2. Otherwise, it will be aligned by 1. To accurately
calculate the offset of the fields, we parse the definition of the
data structure, and find the compiler option of the data structure.
If no compiler option indicates the memory layout of the data
structure, we use the default one, otherwise we use the one defined
by the compiler option. The other is the flexible size array
problem~\cite{flexiblearray}, if the field is a
flexible size array, %(TYPE\_CODE is ARRAY\_TYPE and TYPE\_SIZE is NULL),
its size will not be determined by the compiler, as such we cannot
re-arrange it to other places but the end of the data structure. To
solve this problem, SALADS will record this flexible size array
field in our extraction component, and when it steps into the
randomization
component, it will mark this field un-randomizable.%insert a statement to set
%``$F_r$[i][j]" as 1 in the randomization record before the data structure
%randomization pass. After recording each data structure information,
%we calculate the total number of the data structure and the maximum
%number of field (\textbf{TO PING: Question, not clear here}).
%

\vspace{0.1in}  \noindent \textbf{Identifying External and Shared
APIs.} %We collect external and shared API in function
%\texttt{c\_parser\_declarati-}\\\texttt{on\_or\_fndef} (in
%gcc/c-parser.c).
We record all the functions that contain no body
definition as the external APIs. Shared APIs are those functions
used by other programs (e.g., the system call functions in OS kernel
and the library functions in \texttt{GNU LIBC}). To identify the
shared API, it requires a priori knowledge (i.e., a white list) of
the functions which will be used externally when compiling a
software, and such knowledge can be easily acquired. %For example, we
%know about the system calls for an OS kernel are shared APIs, and
%for Linux kernel,
%
%At this process, we also mark the functions that will be shared with
%other programs. It depends on the priori knowledge of the definition
%of the functions using the name or the location of the functions.
% we can retrieve the system call definition in
%\texttt{include/linux/syscalls.h} and mark them as shared APIs.% the system call name and
%its file location (expand\_location(struct\_loc)), and mark these
%functions as shared API.
